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SYSTEM AND METHOD FOR PROVIDING COMPONENTIZED 
TRANSPORTS AND FORMS 

Field of the Invention 

The present invention relates generally to computer-executable software, 
and more particularly to sending a message across multiple transport protocols. 

Background of the Invention 

Consumer electronics of almost any size now include controllers or 
processors and perform many functions that used to be exclusively within the domain of 
the desktop computer. One such device, the cellular phone, previously dedicated to 
transmitting only voice conmiunication, is now being utilized to transmit other data in 
addition to voice communication. Some cellular phones now allow users to connect to 
the Intemet and browse web sites; other cellular phones now allow users to check and 
send email. However, power consumption and available memory, place size and 
resource constraints on mobile devices, such as cellular phones, that do not exist on 
desktop computers. 

The traditional model of building monolithic applications for the desktop 
world creates difficulties when adapted to mobile computing. Until now, the size and 
resource constraints of mobile devices have made an acceptable communications 
mechanism unascertainable to the developers of mobile coramunications. 

Summary of the Invention 

The present invention provides a system and method for managing 

communication messages on a mobile device with a group of interactive and 

modularized components. The invention provides an email appUcation for mobile 

devices that heretofore had been integrated and non-extensible, allowing them to 

become modular and extensible. The resultant communication system allows easy 

accessorizing by developers. Furthermore, the invention provides a method for 

centrally controlling data flow throughout the conomunication system. 
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In one aspect of the invention, an application is in communication with a 
data storage component, a message forai, a transport, and a data store. The application, 
the message form and the transport each communicate using a standardized set of 
Application Programming Interfaces (APIs) to pass information back and forth. The 
standardized set of APIs enables developers the flexibility to create modularized 
components for performing specialized functions of the communication system, thereby 
avoiding the monolithic approach to appHcation development. In this way, the 
communication system maybe more easily tailored for specific apphcations without 
unduly burdening the Hmited resources of a mobile device. 

The invention simplifies controlling a messaging system by dividing 
particular functionality among several components rather than integrating all the 
functionality in a single component. In addition, each component can use the 
standardized set of APIs to commxmicate. These simplifications improve the abiUty of 
outside vendors to add new components to the system. 

Brief Description of the Drawings 

FIGURE 1 is a functional block diagram illustrating functional 
components of a mobile computing device that maybe adapted to implement one 
embodiment of the present invention. 

FIGURE 2 is a functional block diagram illustrating a system adapted to 
organize and distribute messages. 

FIGURE 3 is a functional block diagram illustrating a subsystem of the 
system illustrated in FIGURE 2, including a mail application and message form, and 
focusing on the relationship of these two components, in accordance with one 
embodiment of the present invention. 

FIGURE 4 is a functional block diagram illustrating a subsystem of the 
system illustrated in FIGURE 2, including a mail application and a transport 
component, and focusing on the relationship of these two components, in accordance 
with one embodiment of the present invention. 



FIGURE 5 is a functional block diagram illustrating the evaluation of a 
message and the instantiation of the appropriate form by the mail application according 
to one embodiment of the present invention. 

FIGURE 6 is a logical flow diagram illustrating a process for accessing a 
registry to identify a proper form to handle a message class, in accordance with one 
implementation of the present invention. 

Detailed Description of the Preferred Embodiment 

The present invention provides a system and method for facilitating the 
management of messages within an electronic device. Among other things, disclosed is 
a system that standardizes the interaction of components of a mobile device messaging 
system. The system allows the mobile device messaging system to be modular and 
extensible. This system is beneficial in a reduced memory capacity environment. 
Illustrative Operating Environment 

FIGURE 1 is a functional block diagram illustrating functional 
components of a mobile computing device 100. The mobile computing device 100 has 
a processor 160, a memory 162, a display 128, and a keypad 132. The memory 162 
generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., 
ROM, Flash Memory, or the like). The mobile computing device 100 includes an 
operating system 164, such as the Windows CE operating system from Microsoft 
Corporation or other operating system, which is resident in the memory 162 and 
executes on the processor 160. The keypad 132 may be a push button numeric dialing 
pad (such as on a typical telephone), a multi-key keyboard (such as a conventional 
keyboard), or other such input device, which would function in the required fashion. 
The display 128 may be a hquid crystal display, or any other type of display commonly 
used in mobile computing devices. The display 128 may be touch sensitive, and would 
then also act as an input device. 

One or more application programs 166 are loaded into memory 162 and 
run on the operating system 164. Examples of apphcation programs include phone 
dialer programs, email programs, scheduhng programs, PIM (personal information 



management) programs, word processing programs, spreadsheet programs, Internet 
browser programs, and so forth. The mobile computing device 100 also includes non- 
volatile storage 168 within the memory 162. The non- volatile storage 168 may be used 
to store persistent information which should not be lost if the mobile computing 
device 100 is powered down. The appUcations 166 may use and store information in 
the storage 168, such as e-mail or other messages used by an e-mail appUcation, contact 
information used by a PIM, appointment information used by a scheduling program, 
documents used by a word processing application, and the like. A synchronization 
application also resides on the mobile device and is programmed to interact with a 
corresponding synchronization application resident on a host computer to keep the 
information stored in the storage 168 synchronized with corresponding information 
stored at the host computer. 

The mobile computing device 100 has a power supply 170, which may 
be implemented as one or more batteries. The power supply 170 might further include 
an external power source, such as an AC adapter or a powered docking cradle that 
supplements or recharges the batteries. 

The mobile computing device 100 is also shown with two types of 
external notification mechanisms: an LED 140 and an audio interface 174. These 
devices may be directly coupled to the power supply 170 so that when activated, they 
remain on for a duration dictated by the notification mechanism even though the 
processor 160 and other components might shut down to conserve battery power. The 
LED 140 may be programmed to remain on indefinitely until the user takes action to 
indicate the powered-on status of the device. The audio interface 174 is used to provide 
audible signals to and receive audible signals from the user. For example, the audio 
interface 174 may be coupled to a speaker for providing audible output and to a 
microphone for receiving audible input, such as to facilitate a telephone conversation. 

The mobile computing device 100 also includes a radio 172 that 
performs the function of transmitting and receiving radio fi-equency commimications. 
The radio 172 facilitates wireless connectivity between the mobile computing 
device 100 and the outside world, via a communications carrier or service provider. 



Transmissions to and from the radio 172 are conducted under control of the operating 
system 164. In other words, communications received by the radio 172 may be 
disseminated to application programs 166 via the operating system 164, and vice versa. 
Illustrative Message Organizing System 
5 FIGURE 2 is a functional block diagram illustrating a system 200 

adapted to organize and distribute messages within a mobile device, according to one 
embodiment of the invention. Messaging system 200 includes message store 210, data 
store 220, transport component 230, mail appUcation 240, and form component 250. 

Message store 210 is a software component, which acts as a mapping 
10 layer between components of a first message format (e.g., MAPI) and components of a 
second message format (e.g., Windows CE Database format). Additionally, the 
message store acts as a principal notifier to the other components of events that occur in 
g system 200. Data store 220 is a software component which acts as a storage area for 

tJ data in the system. Data store 220 may include a local mail store, a local contacts store, 

M 15 and the like. The data store 220 receives and stores message data from the message 
J store 210. 

f: Transport component 230 is illustrated in detail in FIGURE 4, and 

described below. Briefly described, transport component 230 includes several 
1 1 specialized message transports, each programmed to communicate with local 

i; 20 components in MAPI format, and with external devices via particular protocols (e.g., 
3 SMS, SMTP, FAX, etc.). Transport component 230 includes transports 231, 232, and 

233. Although only three transports are shown, it will be understood that more 
transports could be added or transports could be removed without departing from the 
spirit and scope of the invention. For example, SMS transport 231 is a software 
25 component, interfaced to receive messages in SMS format. SMTP transport 232 is 
another software component interfaced to transmit messages in SMTP format. 
Additional transports 233 might be interfaced to receive any of several different 
communication formats such as, for example, fax data transmission, POP3, IMAP, or 
the like. 
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Mail application 240 is illustrated in detail in FIGURE 3 and 4, and 
described below. Briefly described, mail application 240 is an application software 
component that acts as a principal interface between the user and the system. The mail 
application 240 is programmed to control a special function, such as e-mail usage or 
5 contacts maintenance. As shown, the mail application 240 interacts with the message 
store 210, the message forms 250, and the transports 230. It should be noted that while 
the user primarily interfaces with the messaging system 200 through the mail 
application 240, there may be nimierous appHcations running concurrently with the 
input component, such as, a word processor, calendar, etc. These other applications are 
1 0 not detailed here, as they are not pertinent to the present invention, as it exists in its 
present form, although they may support it or be supported by it presently or in the 
future. 

Form component 250 is illustrated in detail in FIGURE 3, and described 
below. The form component 250 includes forms 251, 252, and 253. Although only 

15 three forms are shown, it will be understood that more forms could be added or forms 
could be removed without departing from the spirit and scope of the invention. Briefly 
described, the form component 250 is a group of special display forms that each 
perform a speciahzed fimction with respect to displaying messages. In other words, 
each form is a software component that may be programmed to either display 

20 information for or to receive information from the user. For instance, SMS form 251 
allows the viewer to receive and to view messages in SMS format. Likewise, internet 
mail form 252 is a message form that allows the user to receive and to view internet 
messages. Similarly, meeting request form 253 allows the user to receive and view 
meeting requests. Additional forms might represent any number of different forms that 

25 may be instantiated by the input component 240 such as, for example, fax message, 
deleted messages, or the like. 

Each of the several components, except the data store 220, communicate 
with each other using a standardized set of messaging interfaces, such as MAPI or a 
subset of MAPI. The several standardized interfaces are specified below in conjunction 

30 with a discussion of the particular interface. These features provide the advantage of 



reducing the duplication of resource and simplifying the development of additional 
modules, which helps conserve space. 

FIGURE 3 is a functional block diagram illustrating a subsystem 300 of 
system 200 including mail apphcation 240 and message form 250, and focusing on the 
5 relationship of these two components. Mail application 240 includes interfaces, which 
it exposes to the message form 250 to allow message form 250 to communicate 
instructions to mail apphcation 240. Although only a single interface is shown, it will 
be understood that more interfaces could be added without departing from the spirit and 
scope of the invention. Each interface includes several methods, of which each 

10 performs a specific operation. When a message form 250 calls an interface, the mail 
application 240 executes the identified method. 

In a preferred embodiment, mail component 240 exposes an 
IMessageFormHost interface 341. The IMessageFormHost interface 341 includes 
methods that allow it to fulfill the aforementioned actions. The ImessageFormHost 

1 5 interface 341, and its methods, are generally described through the following 
pseudocode: 



class IMessageFormHost 
{ 

20 public: 

virtual HRESULT GetParentHWND(HWND* phwnd) _PURE; 

enum eMsgStatus { 
eNotAvailable = 0, 
25 eSent=l, 

ePostponed = 2, 
eDelete = 3, 

eDeletePermanently = 4 

}; 

30 virtual HRESULT FonnClosing(IMessageForm* pform, 

Message* pMsg, eMsgStatus eMsgStat) _PURE; 

// This host method is the same one provided as part of IMailSyncCallBack. 
MAPIMETHOD(GetGlobalSetting)(LPCWSTRpszSetting, LPSPropValue pval) 
35 _PURE; 

MAPIMETHOD(SetGlobalSetting)(LPCWSTRpszSetting, LPSPropValue pval) 
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PURE; 



enum actions { 

actNuU = 0, 
5 actFirst = 0, 

actReplyTo = 1, 

actReplyToAll = 2, 

actForward ^ 3, 

actDelete = 4, 
10 actClose = 5, 

actMoveToFolder = 6, 

actGotoNextMessage = 7, 

actGotoPrevMessage = 8, 

actComposeNew = 9, 
15 actGetFuUMessage - 10, 

actViewAttachment =11, 

actReplyWith = 12, 

actShow= 13, 

actLast 

20 }; 

virtual HRESULT DoAction(IMessageForm'*' pform, Message* pmsg, 

actions act, LPARAM IParam) _PURE; 
virtual HRESULT CreateNewMessage(IMessage** ppmsg) _PURE; 

25 

}; 

The methods above allow message form 250 to communicate several 
different instructions to mail apphcation 240. For instance, one method listed above, 

30 FormClosing, allows message form 250 to tell mail apphcation 240 that the form is 
closing. This allows mail apphcation 240 to prepare to be the foreground window 
again, and also to release any handles to message form 250 that is closing. 

Methods GetGlobalSettings and SetGlobalSettings allow message 
form 250 to determine settings, such as whether or not to include the original text of a 

35 message when replying. The DoAction method allows message form 250 to tell the 
mail apphcation to do something (see above pseudocode, including enumerators). 
Message form 250 can use this method to forward a message, reply to it, go to the next 
message in the hst mail apphcation 240 is displaying, etc. Message form 250 can also 
request that the application create a new mail message. 
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Message form 250 also exposes a standardized set of interfaces. 
Although only two interfaces are shown, it will be understood that more interfaces 
could be added to or interfaces could be removed from message form 250 without 
departing from the spirit and scope of the invention. Each interface includes several 
5 methods, of which each performs a specific operation, any of which may be the reason 
the interface is called. 

In this embodiment, message form 250 includes MessageForm 

interface 351 and IFormProvider interface 352. The IMessageForm interface 351 is 

generally described by the following pseudocode: 

1*^ class IMessageForm : public lUnknown 
{ 

public : 

MAPIMETHOD (Activate) ( 
) PURE; 

15 

MAPIMETHOD(ShowForm) ( 
ULONG ulAction 

) _PURE; 

20 MAPIMETHOD(SetMessage) ( 

WORD wType, 
LPMESSAGE pmsg 

) _PURE; 

25 MAPIMETHOD (CloseForm) ( 

BOOL fSave=FALSE 

) _PURE; 

MAPIMETHOD (PreTranslateMsg) ( 
30 MSG* pmsg, 

BOOL* pfProcessed // Set TRUE if the message taken 

) _PURE; 

MAPIMETHOD (Get Act iveMessage) ( 
35 LPMESSAGE* ppmsg 

) _PURE; 

MAPIMETHOD (OnMessageModified) ( 
ULONG cbid, 
40 LPENTRYID pid, 

LPSPropTagArray props 
) PURE; 
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MAPIMETHOD (SetCaptionText) (LPCWSTR psz 
) PURE; 



}; 



The methods above allow mail apphcation 240 to communicate several 
different instructions to message form 250. For example, Activate() method allows the 
mail application 240 to tell the message form 250 to "take control" of the device, that is, 

5 it will become the active "window", accepting all keyboard input. 

Another method is ShowFormQ, which is used by the mail apphcation 
240 to tell the message form 250 to make itself visible or not visible depending on the 
parameter passed to it. Li one actual embodiment ShowFormQ accepts the same 
parameters as the Win32 ShowWindow() API. 

1 0 Yet another method is SetMessageQ, which is used to set the message 

object that the message form 250 is to display, hi one actual embodiment, once a form 
is displayed on the screen, this method can be used to switch the message that is being 
displayed to the user, without having to create a new form. This results in a significant 
reduction in resources and a corresponding increase in performance. Also, 

1 5 SetMessageQ is used to set the initial message object that a message form 250 is to 
display. 

Still another method is CloseFormQ, which is used to tell a message 
form to close or exit. The method PreTranslateMsgQ is used to help with keyboard 
accelerators, for example, in the Win32 environment. 
20 Yet another method is GetActiveMessageQ, which is used to determine 

the message object that a message form 250 is currently displaying. 

Still yet another method is SetCaptionTextQ, which allows the mail 
application 240 to override the text on the title or task bar of the device. This exists 
mainly for the implementation on the Smart Phone, but isn't critical to the idea of the 
25 invention 

The IFormProvider interface 352 is exposed by a message form 250 

dynamic link library (DLL). It primarily performs the function of determining the icon 

to illustrate in the "message hst" of the mail apphcation. Additionally, IFormProvider 

interface 352 creates read forms and compose forms, both of which are members of the 

30 message form group 250 of special display forms discussed above. The IFormProvider 

interface 352 is generally described by the following pseudocode: 
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class IForitiProvider : public lUnknown 
{ 

public ; 
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30 



35 
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enum FORMTYPE { 
kfNewMsg = 0, 
kf Reply = 1, 
kfReplyToAll = 2, 
kf Forward = 3, 
kfLoad = 4, 
kfReplyWith = 5 

}; 

MAPIMETHOD (GetMsgStatusIconlndex) ( 



LPMAPI FOLDER 

LPENTRYID 

ULONG 

ULONG 

ULONG 

LPCWSTR 

ULONG 

ULONG* 



// 
// 



pfldr, 
pid, 
cbid, 
ff Flags, 
ff Status, 
pszMsgClass, 
cAttachments, 
pnlndex // OUT 



Folder for message 
Id of message 
// count of bytes for the id 
// Flags for the message 
// Status for the message 



Idx for correct glyph 



) PURE; 



MAPIMETHOD (ComposeMessageForm) { 
IMessageFormHost* phost, 



LPMESSAGE 

IMessageForm** 

BOOL 

WORD 

LPMESSAGE 
LP ARAM 



pmsg, // Object to compose 

ppForm, // Form object 

f DeleteOnClose, // TRUE if we delete pmsg 
//when the user cancels. 

wIdType, // Reply, Reply All, Forward 

pMsgBase, // Message to prefill the form 
//if necessary 

IParam // Extra data allowing Read 

//forms to pass info 
//to new compose form. 



PURE; 



MAPIMETHOD (CreateReadForm) ( 

IMessageFormHost* pHost, 
IMessageForm** ppForm, 
LPMESSAGE pmsg 

) PURE; 



Mail application 240 calls the LFormProvider interface 352 and its 
associated methods to communicate a requirement to message form 250. Methods 
50 called include GetActiveMessageQ, to determine the message object that a form is 
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currently displaying, and SetCaptionTextQ, allowing the mail application 240 to 
override the text on the title or task bar of the device. 

Another method is GetMsgStatusIconhidex, which is used by the mail 
apphcation 240 to determine the icon that is placed in the Ust of messages that mail 
5 application 240 presents. This allows customizable icons in the list of messages, (i.e. 
Meeting Requests would get a different icon than regular messages). 

Yet another method, ComposeMessageForm(), is used to request a new 
compose form object from the message form 250. This method creates a new 
hnessageForm object that would allow editing or modifying the message object passed 
10 to it. In one actual embodiment, the form is not visible after creation. The mail 

application 240, after creating the form, calls the hnessageForm: :ShowForm() method 
to make the new form visible. Still yet another method is CreateReadForm(), which is 
used to create a new message form for reading messages. 

FIGURE 4 is a fimctional block diagram illustrating a subsystem 400 of 
15 system 200 including mail apphcation 240 and transport component 230, and focusing 
on the relationship of these two components. Mail apphcation 240 exposes interfaces 
that allow transport component 230 to communicate instructions to mail 
apphcation 240. Additionally, although only a single interface is shown, it will be 
understood that more hiterfaces could be added without departing from the spirit and 
20 scope of the invention. 

In a preferred embodiment, mail apphcation 240 includes 
IMailSyncCallBack interface 441, generally described in the following pseudocode. 

class IMailSyncCallBack : public lUnknown 

25 , 

public: 

MAPIMETHOD (RequestSync) ( 

LPCWSTR pszProfile, 
DWORD cbCookie, 
30 LPBYTE pbCookie 

) _PURE; 

MAPIMETHOD (Progress) ( 

LPCWSTR pszProfile, 
35 SYNCPROGRESSITEM^ pinfo 

) _PURE; 
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MAPIMETHOD(GetGlobalSetting) { 
LPCWSTR pszSetting, 
LPSPropValue pval 
) _PURE; 

MAPIMETHOD_(UINT, DisplayMessageBox) { 
LPCWSTR pszProfile, 
LPCWSTR pszTitle, 
LPCWSTR pszMessage, 
UINT nFlags 
) _PURE; 

MAPIMETHOD (RequestCredentials) { 
LPCWSTR pszProfile, 
SYNCCREDENTIALS* ppcreds Source, 
SYNCCREDENTIALS** ppcreds 
) _PURE; 

MAPIMETHOD (LogEvent) ( 

TRANSPORTEVENT* pevt 
) PURE; 



MAPIMETHOD (AllocateMem) ( 
25 DWORD cbSize, 

LPBYTE* ppb 
) PURE; 



MAPIMETHOD (FreeMem) ( 
LPVOID pvmem 
) PURE; 



}; 



Transport component 230 (such as MAP or POP) uses the 
35 MailSyncCallBack interface 441 to inform the mail apphcation 240 of status changes 
and progress. Additionally, the MailSyncCallBack interface 441 can be used to report 
errors or events which occur, to the mail apphcation 240, allowing the mail 
application 240 to display the error or event. Transport component 230 may also use 
the MailSyncCallBack interface 441 to request that a message be displayed to the user 
40 of the mail application 240. 

Further, transport component 230 may use the MailSyncCallBack 
interface 441 to request authentication credentials from the mail application 240 for an 
account. This request allows the mail apphcation 240 to be a common clearing house 
and safe repository of account data, freeing the transport component 230 of this 
45 responsibility. Additionally, the MailSyncCallBack interface 441 can be used to 
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request global messaging settings as well as to allocate and free shared memory buffers 
between transport component 230 and mail application 240. 

In this embodiment, the transport component 230 exposes an 
ImailSyncCallHandler interface 441, described by the following pseudocode. 



class IMailSyncHandler : public lUnknown 
{ 

public : 

MAPIMETHOD (Initialize) ( 

IMailSyncCallBack^ pCallBack, 
LPCWSTR pszProfileName, 
IMsgStore^ pMsgStore 
) _PURE; 

MAPIMETHOD (ShutDown) { 

DWORD dwReserved 
) _PURE; 

MAPIMETHOD (Synchronize) ( 

MAILSYNCREQUEST* pRqst 
) _PURE; 

MAPIMETHOD (DoProperties) { 
HWND hwndParent 
) _PURE; 

MAPIMETHOD (GetCapability) ( 
LPCWSTR pszName, 
LPSPropValue pval 
) _PURE; 

MAPIMETHOD (SetCapability) ( 
LPCWSTR pszName, 
LPSPropValue pval 
) _PURE; 

MAPIMETHOD (Install) ( 

LPCWSTR pszProfileName, 
LPCWSTR pszIncomingServer, 
LPCWSTR pszOutgoingServer, 
GUID* pidNetwork 
) _PURE; 

MAPIMETHOD (Unlnstall) ( 
) __PURE; 

MAPIMETHOD (DecodeEvent) ( 

TRANS PORTE VENT* pevt, 
LPWSTR* ppszEvent 
) PURE; 
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}; 



MAPIMETHOD(GetFolderHierarchy) ( 
FOLDERNODE^* ppRootNode 
) _PURE; 

enum FOLDEROPTIONS { 
koptNA - 0, 
koptDownload, 
koptQueryDownload, 
koptGetRemotePath^ 
koptCreate, 
koptQueryCreat e ^ 
koptSetAge, 
koptSetBodyFetchSize, 
koptSetAttachFetchSize, 
koptGetAge, 
koptGetBodyFetchSize, 
koptGetAttachFetchSize, 

}; 

MAPIMETHOD (SetFolderOptions) ( 
IMAPIFolder^ pfldr, 
FOLDERNODE^ pnode, 
FOLDEROPTIONS opts, 
LPSPropValue pval 
) _PURE; 

MAPIMETHOD (Connect) { 

DWORD dwReserved, 
SYNCCREDENTIALS* pCredentials 
) _PURE; 

MAPIMETHOD (Disconnect ) ( 
DWORD dwReserved 
) PURE; 



Mail application 240 calls the IMailSyncHandler::Install() method when 
installing a new instance of a transport. This method allows the new instance of the 
transport, to set up any initial registry settings or to create any files necessary for the 

40 new instance of the transport. In one actual embodiment, a "profile name" can be 

passed in the pszProfile parameter, which allows multiple instances of a transport. In 
practice, this is done to allow, for example, the IMAP transport to be installed twice, 
once for your corporate mail account, and once for a personel mail account. In this 
actual implementation of the IMailSyncHandler interface, the profile name is specified 

45 in conjunction with Install(), UninstallQ, and InitiUazeQ methods for maintaining 

several instances of a transport. Also when a transport talks back to the application via 
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the IMailSyncCallback interface, the transport specifies it profile name, so that the 
appUcation knows the context of the request relative to the transport making the 
function call (request). 

Mail appUcation 240 calls IMailSyncHandler::UnInstall() method when 
5 removing an instance of a transport. When called, MailSyncHandler: :UnInstall() 
method removes any values firom the registry, and/or removes any mail that the 
transport may have created, ft-om the mail store. 

IMailSyncHandler::Initiahze() method is used when any transport of 
transport component 230 is loaded. Mail appUcation 240 calls this method to initiaUze 

10 a transport. Another method, the MailSyncHandler: :SetCapability() method, is used to 
modify the behavior of an instance of a transport. For example, mail appUcation 240 
might use this method to change the date range of messages that the transport would 
aquire from the server. Yet another method, MailSyncHandler: :GetCapability() 
method, is used to query a transport setting or capability. 

1 5 StiU another method, MailSyncHandler: :Connect() method, is used to 

instruct the transport to connect to the mail server. MailSyncHandler: :Disconnect() 
method is used to instruct a transport to disconnect from the mail server. The 
MailSyncHandler: :Synchronize() method may be used to instruct a transport to 
synchronize the local mail store against the remote mail server. The 

20 MailSyncHanlder::DecodeEvent() method is used by the appUcation to decode an event 
that transport component 230 has logged to the mail appUcation 240 with 
MailSyncCallback::LogEvent() method, hi operation, MailSyncCallback::LogEvent() 
method allows a transport to log a small packet of data with mail appUcation 240. Mail 
application 240 would the use a DecodeEventQ method to get a human readable 

25 description of the event. 

The MailSyncHandler::GetFolderHierarchy() method, allows querying 
the folder hierarchy of the remote mail server. Finally, the 
MailSyncHandler: :SetFolderOptions() method allows setting and querying sync 
options for folders on the remote mail server. 
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The above listed code and descriptions are not intended to be exhaustive 
in nature but are merely intended to clarify specific portions of the present invention 
and assist in enabling one having ordinary skill in the art to practice the invention. 

FIGURE 5 is a functional block diagram conceptually illustrating a 
5 process the mail application 240 uses to determine a proper form, to instantiate based on 
message 500. Form 550 represents one instance of any form within the group of 
forms 250, including a default form for situations where a specific form is not requested 
or where a requested form cannot be provided. 

Message 500 is a commimication message, such as an e-mail message, 

1 0 stored on the mobile device 1 00. The message 500 includes a class property 5 1 0 as 
well as additional message properties 520. The class property 510 is an object 
including apropertyname field 511 and a value field 512. For example, property 
name field 5 1 1 might be PR_MESSAGE_CLASS, which identifies the property, while 
the corresponding value field 512 might be a text string describing the class of the 

1 5 message. An example of one particular message class might be 
IPM.MEETINGREQUEST.ACCEPT. 

The registry 530 is a registration database containing, among numerous 
other things, pertinent information relating to the forms of form component 250 
registered in the system. The registry 530 includes entries that associate particular 

20 message classes with a registered form to handle messages of that particular class. For 
example, as shown in FIGURE 5, Form "A" is registered to handle the 
IPM.MEETINGREQUEST.ACCEPT message class 531. Likewise, Form "B" is 
registered to handle the IPM.NOTE message class 532. The registry 530 may be a part 
of the operating system. 

25 Briefly stated, in operation, mail appUcation 240 determines the 

appropriate form to instantiate by first locating class property 510 and identifying the 
message class. Mail application 240 then queries the registry 530 to determine which 
form is registered to handle the identified message class. Mail appHcation 240 then 
instantiates the registered form 550 and passes to it the message data. 
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In the event the message class does not have a registered form, a default 
form is utilized. For example, IPM.NOTE form handler 532. The default form allows 
messages received in unregistered forms to be received by the message system and 
therefore displayed to the user. 
5 FIGURE 6 is a logical flow diagram generally illustrating a process for 

accessing a registry to identify the proper form to handle a message class. In describing 
FIGURE 6, reference is made to the system described in conjunction with FIGURES 2 
and 5. Method 600 enters at starting block 601, where message data typically is already 
available, such as, for example, at transport component 230 or stored within the data 
10 store 220. 

The process begins at block 603 where, for example, one or more 
components, such as the transport component 230, notifies mail application 240 that the 
component has message data to pass to a message form 250. At block 605, the mail 
apphcation 240 retrieves the class property 510 from the message data, as described 

15 above in conjunction with FIGURE 5. 

At block 607, mail apphcation 240 accesses the registry 530 to identify 
the appropriate message form 550 registered to handle the message class. In the event 
there is not a form registered to handle the identified message class, the registry may 
identify a default form handler to mail application 240. 

20 At block 609, mail apphcation 240 invokes the identified form 550. At 

block 611, mail application 240 passes the message properties to the message form 250 
using a standard interface, as described above. At block 615, processing ends. At this 
point the message data has been passed to the appropriate message form 250. It should 
be noted that this process may be used by any component in the messaging system 200 

25 that communicates with mail apphcation 240, and requires a form 550. 

The above specification, examples and data provide a complete 
description of the manufacture and use of the composition of the invention. Since many 
embodiments of the invention can be made without departing from the spirit and scope 
of the invention, the invention resides in the claims hereinafter appended. 

30 
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